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INTRODUCTION 


Optimal allocation and usage of resources is a key to 
effective management. 

Resources of concern to TRAC are: Manpower (PSY), 
Money (Travel, contracts), Computing, Data, Mod- 
els, etc. 

Management activities of TRAC include: Planning, 
Programming, Tasking, Monitoring, Updating, and 
Coordinating. 

Existing systems are insufficient; not completely au- 
tomated; manpower intensive; potential for data in- 
consistency exists. 

Proposed system provides a means to integrate all 
project management activities of TRAC through the 
development of a sophisticated software and by uti- 
lizing the existing computing systems and network 


resources. 




EXISTING SYSTEM ARCHITECTURE 


Independent systems for Study Program, Work Pro- 
gram, Manpower Utilization Reporting, Taskers, and 
Tracking Data Requests. 

Study Program: 

1. The system is developed using DBASE-3 on IBM- 
PC. 

2. This database only resides at RPD and is also 
accessed by RPD only. 

3. The system does not store the history of a study 
over its life time. It can only store information on 
three consecutive fiscal years (past, current, and 
next) at any given point. 

4. RPD mails the software on a floppy to TRADOC 
agencies. Users enter study request information 
using this software and send this information elec- 
tronically or by US mail to RPD. 

5. RPD merges the requests and arrives at a consol- 
idated list. 




6. No history of changes to the study program is 
maintained. The original information is itself changed 
to reflect any new changes. 

7. Status of the Studies in the program are printed 
once in a quarter and disseminated. 

Work Program: 

1. No automatic linkage between the study program 
and work program exists at present. 

2. Changes in the study program are not automat- 
ically reflected in the work program. Manual in- 
tervention is necessary to make these changes. 

Manpower Utilization Reporting: 

1. An independent system, MURS, maintains man- 
power utilization information. 

2. MURS is developed on DBASE-3 to run on a PC. 

It is being ported to run on Foxbase on Intel. 

3. Each agency enters its manpower usage informa- 
tion and mails the floppy to TRAC RPD. RPD 
consolidates the information. 

4. There is no automatic linkage between MURS and 
Work Program. 




Taskers: 

1. DBASE-3 based system is used to track status of 
taskers. There is no automatic link between the 
study program database and this system. 

2. Only RPD maintains it and uses it. 




PROPOSED SYSTEM ARCHITECTURE 


• A distributed database system - the TRAC agencies 
are the processing sites connected through a network. 

• TRAC RPD at Fort Monroe is the principal site and 
contains additional software to maintain global con- 
sistency of data. 

• The communication system consists of the Ethernets 
at the local sites, the IBM/SNA network, MILNET, 
and the networking through the Tracer. 

• Each TRAC site contains a copy of the entire database. 

• Non-TRAC sites will continue to interact with RPD 
by exchanging information non-interactively (e.g. Mail 
floppies). 

• A site may contain either ORACLE software or DBASE- 
3 software. 

• Each site functions autonomously for both data access 
and updates. In addition, a user at a site needs to 
access only the local copy of the database. 



The failure or unavailability of a site or communica- 
tion channel will not affect the functionality of other 
available sites. 

The access rights to the data elements are clearly de- 
fined on a need-to-know basis. This will be imple- 
mented using the security features of the database 
software (ORACLE or DBASE-3) augmented with 
additional software developed by us. 

The distribution of data will be transparent to the 
TRAC users. That is, users need not be concerned 
about the data distribution. 




PROPOSED SYSTEM FEATURES 


1. The database is an integrated TRAC decision support 
system. 

2. Updations made at a local site are automatically prop- 
agated to all relevant sites. To minimize network us- 
age, updates will be propagated once or twice in a 
day. 

3. In case a local site is down, it may be possible for 
users at that site to access database at other sites (or 
at least at the principal site). 

4. Fast (local) access to data at any of the TRAC agen- 
cies. 

5. A user friendly interface. 

6. Multi-level security to the information in the database. 

7. Fast and easy dissemination of information. E.g. Changes 
in Study Program. 




8. Insure consistency within TRAC data. 

9. Minimize duplication of efforts. 

10. Ability to compare the actual versus planned utiliza- 
tion of resources. 

11. On-line access to results (intermediate/final) from a 
study. 




SUMMARY OF PLAN 


• PHASE I: Since Study Program is the basis for a 
majority of TRAC activities, this will be taken up 
in this phase. In addition, this phase will solve the 
major problems related to distribution of data and 
communication between the sites. It will extend the 
existing Study Program information by adding Tasker 
scheduling information. 

• PHASE II: This will extend the database to include 
Work Program and Manpower Utilization informa- 
tion. 

• PHASE III: This extends the system to include data 
request tracking, model requests, monitoring of sched- 
ules, etc. 



PHASE I - DEVELOPMENT 


STUDY PROGRAM 


• Guidance for AR 5-5 Study programs for next fiscal 
year. 

• Requests for new or continuing studies for next fiscal 
year. 

• Assign priorities. 

• Authorize studies. 

• Allocate resources. 

• Tasker scheduling information. 

• Update the program: termination, deletion, addition, 
updation, or completion. 

• Past history to guide future programs. 

• Handle arbitrary queries on the past, current, and 
next study programs. 




PHASE I BENEFITS 


• The latest guidelines are available on-line at the users’ 
site. 

• Possible to implement a complex priority scheme. This 
procedure can also be made available to the agencies. 

• Since the study requests made so far are available at 
the RPD and other sites, it is possible to eliminate 
duplications at an early stage. 

• By automatic linking of study authorization with re- 
source allocation, speed and consistency can be achieved. 

• Since agencies can update the status of a study lo- 
cally, this information is more likely to be up-to-date. 

• Since the status of a study is available to all agencies, 
other agencies can easily use this information for their 
planning. 

• If reports, results etc. coming out of a study are made 
available at the agency’s site, they can be easily re- 
trieved by other agencies. 

• Ability to access the data on previous programs in- 
creases the efficiency of future programs. 

• Ability to handle arbitrary queries improves turn- 
around time of responses. 

• It is possible not only to update a program, but also 
include comments indicating the reasons for the changes. 




MAJOR TASKS IN PHASE I 


1. System Requirements: An in-depth study of the 
Study Program and Taskers. It is also necessary to 
study how the decisions in this phase will influence 
development of other phases. 

2. ORACLE Database: Study and experiment with 
the ORACLE software to determine its features, cost 
of these features, and its limitations. 

3. DBASE-3 Database: Study and experiment with 
the DBASE-3 software to determine its features, cost 
of these features, and its limitations. 

4. Security: Study and test the security features of- 
fered by ORACLE and DBASE-3. Check if these 
satisfy the TRAC’s requirements. If not, determine 
ways to provide the additional security. 




5. Communications: Study and experiment with the 
available communication facilities at TRAC. If the 
existing communication software cannot be directly 
used by the distributed database system, then some 
additional communication software may need to be 
developed to achieve the desired functionality: secu- 
rity, efficiency, and ease of use. 

6. Heterogeneity: Since we are dealing with two dif- 
ferent database software systems, we need to deal 
with the problems of heterogeneity. This requires the 
study of interoperability issues. 

7. Update Protocols: Since the updates are made lo- 
cally (at the sites) and sent to the primary site (RPD) 
at designated times, we need to develop a special mon- 
itor process that can accumulate the updates within 
a period and forward it to the primary site. Similarly, 
we need to develop a process at the primary site that 
can reliably propagate updates to all the TRAC sites. 
Reliability is the key. Issues such as the unavailabil- 
ity of a site, unavailability of a communication chan- 
nel, and faulty communication channels need to be 
considered here. 



8. Consistency Checks: In addition to the update 
protocols, it may be necessary to run some global 
consistency check protocols, probably run once in a 
week, to check the consistency of the global database. 

9. Communication Security: Depending on TRAC’s 
requirements, if the security offered by the existing 
communication systems for data transmission is insuf- 
ficient, additional methods such as encoding or data 
compression may need to be developed and tested. 

10. Database Design: Having studied the users’ re- 
quirements, a database system needs to be designed. 
This requires the definition of the fields and their 
type, design of the relations, deciding the type of in- 
dexing, selection of additional secondary index tables, 
etc. To keep the data meaningful, we also need to 
arrive at some integrity constraints defined on the re- 
lations. 

11. Query and Form Design: Write code (for ORA- 
CLE and DBASE-3) to execute the desired queries 
and print reports. This should be done at least for 
the existing reports and some known types of queries. 
However, a user may have to develop code for any 
special queries not covered in this phase. 




12. User Interface: Depending on the facilities offered 
by ORACLE and DBASE-3 and depending on the so- 
phistication of the TRAC’s requirements, additional 
efforts may have to be expended to design a user in- 
terface to the decision support system. 

13. Implementation: The system needs to be imple- 
mented on ORAACLE and DBASE-3. It also needs 
to be rigorously tested. 

14. Actual Data: Once the testing phase is completed, 
the system is ready to be used. The actual data may 
now be placed into the system. 

15. User Training: All TRAC users (or their represen- 
tatives) need to be trained on system usage. 

16. Complaints/Comments: We should also provide 
an automatic system to register any problems or im- 
provements needed by the database system users. These 
should be looked into by the RPD personnel. 




SCHEDULE FOR PHASE I 


Activity 

Time 

(in Weeks) 

Period 

System Requirements: Development 

4 

May’90 

ORACLE Software: Study k experiment 

3 

May’90 

DBASE-3 Software: Study k experiment 

2 

May’ 90 

Database Security: Study k Develop 

6 

June-July’90 

Communications: Study k Develop 

5 

June-July’90 

Update Protocols 

4 

June-July’90 

Communication Security 

4 

Aug’90 

Database design 

4 

Aug’90 

Consistency and Integrity 

4 

Sept’90 

Query and Form Design 

4 

Sep’90 

User Interface 

6 

Sep-Oct’90 

Implement and Test 

4 

Oct’90 

Incorporation of Actual data 

2 

Nov’90 

Complaint / Comment Software 

3 

Nov-Dec’90 

Documentation and User Training 

4 

Dec’90 





FEASIBILITY 


ORACLE and DBASE-3 are two well established and 
proven database software systems. Since the pro- 
posed system is based on these, the chances of success 
axe very high. 

A communication network system already exists be- 
tween ah TRAC sites. Even though it is only being 
used for Email, it should not be difficult to develop 
the required communication software on top of the ex- 
isting system. The expertise of Mr. Hugh Dempsey, 
CIO, wih be sought in developing this software. 

The staff at RPD are well versed with the existing 
systems. They are also clear on the inclusions to be 
made in the proposed system. This would make the 
system requirement development an easy task. 




• The principal investigator, Ravi Mukkamala, is well 
versed with the issues and problems that arise in a 
distributed database system. Thus, protocol devel- 
opment for propagation of updates, data consistency, 
and handling site/link failures should not be difficult. 
Issues that require complete knowledge of ORACLE 
and DBASE-3 can be solved once these two systems 
are studied and experimented with. 

• Implementing data security and communication se- 
curity may be the most difficult tasks. Once again, 
we need to study the two database softwares and the 
communication systems to arrive at concrete code. 

• Query and form design is not difficult. Both the ODU 
students that are committed (if paid) to this project 
are familiar with SQL. They have extensive experi- 
ence in programming on DBASE-3. In addition, RPD 
staff currently handling the databases, are also very 
well versed with DBASE-3 programming. 




EXTENSIBILITY AND MAINTAINABILITY 


• Since the proposed system is based on a commercial 
database product, it should be easy to modify the 
database. The current RPD staff will be able to make 
changes related to: adding fields, creating additional 
relations, adding more queries, modifying the existing 
queries, etc. 

• The problems in communications systems are more 
severe. They require the expertise of RPD staff such 
as Mr. Hugh Dempsey. If the communication sys- 
tem between the TRAC agencies is changed, then the 
communication software of this system also needs to 
be changed. 

• Modifying the user-interface, once developed, may be 
more involved. The degree of difficulty will depend 
on its structure and the familiarity of the RPD staff 
with this software. Training one or two staff members 
at RPD may solve this problem. 

• Extending the system from Phase-I to other phases 
should not be difficult due to the extensibility of re- 
lational database structures. 




COST AND BENEFITS 


The ODU team will consist of the principal investiga- 
tor and two graduate students. Each of the graduate 
students should be paid about $8,000 for the dura- 
tion of the project. The principal investigator should 
be paid $15,000 as a summer salary and some release 
time during the Fall semester. Total: $31,000 

The ODU Research Foundation charges an overhead 
of 45%. In this case it would be $13,950. The overall 
cost up to Phase I is approximately $45,000. 

As a result of implementing the proposed system, 
TRAC can reduce duplication of efforts in maintain- 
ing different databases, achieve data consistency, and 
establish a strong base for an effective decision sup- 
port system. 



PHASE II - EXPANSION 


INTEGRATION OF STUDY PROGRAM WITH WORK 
PROGRAM AND MURS. 


PHASE III - FURTHER INTEGRATION 


INTEGRATION OF DATA TRACKING, MODELS, 
AND SCENARIOS. 




SUMMARY OF PLAN 


• PHASE I: Since Study Program is the basis for a 
majority of TRAC activities, this will be taken up 
in this phase. In addition, this phase will solve the 
major problems related to distribution of data and 
communication between the sites. It will extend the 
existing Study Program information by adding Tasker 
scheduling information. 

• PHASE II: This will extend the database to include 
Work Program and Manpower Utilization informa- 
tion. 

• PHASE III: This extends the system to include data 
request tracking, model requests, monitoring of sched- 
ules, etc. 





